<html>
<head><meta charset="utf-8"><title>Diagnostics working group? · t-compiler/rust-analyzer · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/index.html">t-compiler/rust-analyzer</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html">Diagnostics working group?</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="232253171"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232253171" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232253171">(Mar 29 2021 at 11:33)</a>:</h4>
<p>Hey, with proc-macros enabled by default, I think we no longer have excuses for not producing diagnostics for everything we can diagnose. It seems like it's high time to make our diagnostics infra "production ready". This includes three things:</p>
<ul>
<li>Figuring our the appropriate "pattern" for doing diagnostics, which accounts for salsa incrementality, desugarings, id-based structure of things inside rust-analyzer and IDE specific concerns. </li>
<li>Cleaning-up diagnostics API in rust-analyzer, such that it's easy to emit and consume diagnostics (today that's horribly complicated in comparison to, eg, assisgs)</li>
<li>Polishing user-experience (squishing false positeves, implementing fixits, polishing error messages and ranges)</li>
</ul>
<p>This sounds like a great task for the next sprint. Anyone is interested in this topic?</p>



<a name="232257313"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232257313" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232257313">(Mar 29 2021 at 12:08)</a>:</h4>
<p>also a strategy for merging our diagnostics with rustc's, IMO</p>



<a name="232257378"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232257378" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232257378">(Mar 29 2021 at 12:09)</a>:</h4>
<p>starting to emit typechecker diagnostics is my plan after finishing the chalk_ir move as well</p>



<a name="232258083"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232258083" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232258083">(Mar 29 2021 at 12:16)</a>:</h4>
<p>so, I guess I am interested, but currently still mostly focused on Chalk</p>



<a name="232258510"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232258510" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232258510">(Mar 29 2021 at 12:19)</a>:</h4>
<p><span class="user-mention" data-user-id="129457">@Florian Diebold</span> by "merging" you mean deduplication in the UI, or sharing some common library?</p>



<a name="232258571"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232258571" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232258571">(Mar 29 2021 at 12:20)</a>:</h4>
<p>yeah, deduplication</p>



<a name="232259183"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232259183" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232259183">(Mar 29 2021 at 12:25)</a>:</h4>
<p>That falls under "polishing UX". Shouldn't be too hard -- we need to match diagnostic codes and see if the ranges intersect.</p>



<a name="232259210"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232259210" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232259210">(Mar 29 2021 at 12:25)</a>:</h4>
<p>yeah</p>



<a name="232259326"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232259326" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232259326">(Mar 29 2021 at 12:26)</a>:</h4>
<p>Well, there's this infinitelly annoying issue that VS Code won't shift ranges of diagnostics on editing, but I don't feel we can do anything on our side to fix it, short of using Emacs instead.</p>



<a name="232259417"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232259417" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232259417">(Mar 29 2021 at 12:27)</a>:</h4>
<p>hmm. I think we've previously discussed this, but isn't this a problem with the rustc diagnostics specifically because we only refresh them on save, but (have to) resend them on every change?</p>



<a name="232259432"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232259432" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jonas Schievink  [he/him] <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232259432">(Mar 29 2021 at 12:27)</a>:</h4>
<p>yeah, I think that's on us</p>



<a name="232259542"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232259542" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232259542">(Mar 29 2021 at 12:28)</a>:</h4>
<p>When we get the diagnostics form rustc could we try to match the spans to tokens and store some relatively stable id for the tokens? And then re-compute the spans every time we push the diagnostics to the editor.</p>



<a name="232259597"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232259597" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232259597">(Mar 29 2021 at 12:29)</a>:</h4>
<p>That works for check on save diags, but not from the ones that are produced by a problem matcher (I think?)</p>



<a name="232259679"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232259679" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232259679">(Mar 29 2021 at 12:29)</a>:</h4>
<p>Probably. But at least it may solve half of the problem.</p>



<a name="232259767"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232259767" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232259767">(Mar 29 2021 at 12:30)</a>:</h4>
<p>the problem matcher is a pure VSCode issue anyway, the problem with the check on save diagnostics exists in every client</p>



<a name="232260066"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232260066" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232260066">(Mar 29 2021 at 12:33)</a>:</h4>
<p>Also, as a general reminder, there's this grand diagnostics dilemma  for IDEs:</p>
<ul>
<li>we can compute diagnostics only for the open files, ensuring roughly O(1) work for O(1) edit</li>
<li>we can compute all diagnostics, ensuring better overall user experience</li>
</ul>
<p>At the moment, rust-analyzer works in the first paradigm. It might be the case that, with explicit crate graph, good incremental and fast implementation, the second would be feasible even for arbitraty big projects. </p>
<p>IntelliJ does <code>1</code> as well. Roslyn I believe dos <code>2</code> by default, but they have a checkbox to switch to <code>1</code> for large projects.</p>
<p>This also intersects with the search dilemma -- should we use tri-gram text search + semantic prunning (today's approach) or sould we search semantic info directly?</p>



<a name="232260274"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232260274" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232260274">(Mar 29 2021 at 12:34)</a>:</h4>
<p>An option to switch between the two methods would be nice.</p>



<a name="232260466"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232260466" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232260466">(Mar 29 2021 at 12:36)</a>:</h4>
<blockquote>
<p>This also intersects with the search dilemma -- should we use tri-gram text search + semantic prunning (today's approach) or sould we search semantic info directly?</p>
</blockquote>
<p>The current way doesn't result in reduced accuracy, right?</p>



<a name="232260535"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232260535" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jonas Schievink  [he/him] <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232260535">(Mar 29 2021 at 12:36)</a>:</h4>
<p>For macros it does</p>



<a name="232260578"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232260578" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jonas Schievink  [he/him] <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232260578">(Mar 29 2021 at 12:37)</a>:</h4>
<p>We could make it expand <em>every single macro</em> and search the outputs too</p>



<a name="232260605"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232260605" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232260605">(Mar 29 2021 at 12:37)</a>:</h4>
<p>personally, I would prefer 1) with a button that lists all diagnostics everywhere and lets you jump to them</p>



<a name="232260775"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232260775" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jonas Schievink  [he/him] <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232260775">(Mar 29 2021 at 12:39)</a>:</h4>
<p>I think we need GC in order to make option 2 work in practice</p>



<a name="232270914"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/232270914" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jeremy Kolb <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#232270914">(Mar 29 2021 at 13:50)</a>:</h4>
<p>Diagnostic pull support is being played with right now for LSP 3.17</p>



<a name="233890518"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/233890518" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jonas Schievink  [he/him] <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#233890518">(Apr 09 2021 at 21:05)</a>:</h4>
<p>This working group would probably be interested in building more general infra for diagnostics, so that we won't have to check <code>#[allow]</code> attributes for every single diagnostic</p>



<a name="233978968"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/233978968" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jonas Schievink  [he/him] <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#233978968">(Apr 10 2021 at 19:05)</a>:</h4>
<p>I also think we should, at some point:</p>
<ul>
<li>come up with a policy for when a diagnostic is "experimental" or not</li>
<li>disable experimental ones by default</li>
</ul>
<p>...because they do tend to annoy users more than I'd like</p>



<a name="233979767"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/233979767" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#233979767">(Apr 10 2021 at 19:17)</a>:</h4>
<p>we do get a lot of useful bug reports that way though ;) ... maybe we could deactivate them in weekly builds, but keep them in nightlies and self-compiled</p>



<a name="233979867"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/233979867" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#233979867">(Apr 10 2021 at 19:18)</a>:</h4>
<p>OTOH there's a certain degree of experimentalness I would keep turned off by default all the time (e.g. if we were to add type mismatch errors right now)</p>



<a name="233980042"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/233980042" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jonas Schievink  [he/him] <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#233980042">(Apr 10 2021 at 19:21)</a>:</h4>
<p>yeah the bug reports are very useful</p>



<a name="233980078"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/233980078" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jonas Schievink  [he/him] <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#233980078">(Apr 10 2021 at 19:22)</a>:</h4>
<p>it'd be nice if we could offer a quick fix that turns off a diagnostic</p>



<a name="233980123"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/233980123" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jonas Schievink  [he/him] <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#233980123">(Apr 10 2021 at 19:22)</a>:</h4>
<p>don't think it's possible to make that persistent though</p>



<a name="233980131"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/233980131" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jonas Schievink  [he/him] <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#233980131">(Apr 10 2021 at 19:22)</a>:</h4>
<p>well, only in an ad-hoc way at least</p>



<a name="234036043"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/234036043" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Laurențiu <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#234036043">(Apr 11 2021 at 11:00)</a>:</h4>
<p>In Code we can, I guess</p>



<a name="234036365"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/234036365" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#234036365">(Apr 11 2021 at 11:05)</a>:</h4>
<p>we could by making it possible to disable the diagnostics either in Cargo.toml or with attributes</p>



<a name="234036434"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/234036434" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#234036434">(Apr 11 2021 at 11:06)</a>:</h4>
<p>of course people might not want to spam their code with rust_analyzer::allow attributes</p>



<a name="234036482"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/234036482" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#234036482">(Apr 11 2021 at 11:07)</a>:</h4>
<p>then again, maybe the diagnostics where that would happen a lot would be better off disabled by default</p>



<a name="234036549"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/234036549" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#234036549">(Apr 11 2021 at 11:08)</a>:</h4>
<p>(obviously, the more false positives a diagnostic has, the less we need feedback from users for it...)</p>



<a name="234036602"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/234036602" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#234036602">(Apr 11 2021 at 11:09)</a>:</h4>
<p>maybe we could have a policy of "diagnostics that trigger on the RA codebase (and maybe also codebases X and Y) can't be on by default"</p>



<a name="239437964"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239437964" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jonas Schievink  [he/him] <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239437964">(May 19 2021 at 14:51)</a>:</h4>
<p>One thing this working group might be interested in is rustc's approach at making diagnostics compatible with incremental computation. It works by storing them all in a <code>Vec</code> while a query executes, and the query system effectively makes them part of the query result.</p>
<p>This sounds like a solution that could make our lives a lot easier, since we wouldn't have to manually buffer and emit them from every place that could possibly want to produce a diagnostic.</p>



<a name="239438010"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239438010" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jonas Schievink  [he/him] <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239438010">(May 19 2021 at 14:51)</a>:</h4>
<p>This would require salsa support however</p>



<a name="239446591"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239446591" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239446591">(May 19 2021 at 15:34)</a>:</h4>
<p>I have doubts that approach would work for us? We still have to know which queries to trigger to get 'all' diagnostics anyway</p>



<a name="239446820"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239446820" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239446820">(May 19 2021 at 15:36)</a>:</h4>
<p>I mean, it might be nice to not have to collect the diagnostics explicitly, but I don't know if it's worth it</p>



<a name="239883055"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239883055" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239883055">(May 22 2021 at 16:07)</a>:</h4>
<p>I'm wondering a bit on what level diagnostics should actually exist. Are they an IDE thing, or a HIR (Semantics) thing? obviously things like type errors or missing match arms need to ultimately come from the compiler infrastructure, but should things like "replace filter_map(...).next() with find_map(..)"? At least we'd want this kind of thing to be implementable quite separately from the compiler parts (maybe even with plugins). OTOH we still need it to be integrated in Salsa. And quick fixes should almost certainly be calculated by the IDE parts and probably not live in the DB.</p>



<a name="239883289"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239883289" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239883289">(May 22 2021 at 16:10)</a>:</h4>
<p>maybe the answer is that we shouldn't / don't need to have a unified concept of diagnostics in the HIR crates, just collect various kinds of errors that could be simple, disparate enums (e.g. one <code>TypeError</code> enum for various errors emitted during inference). And then those could be collected and turned into proper diagnostics by the same IDE-level mechanism that would also calculate purely IDE-level lints like <code>replace-filter-map-next-with-find-map</code></p>



<a name="239883392"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239883392" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239883392">(May 22 2021 at 16:12)</a>:</h4>
<p>and that one would probably not need to keep structured information about the error, which would make the whole <code>dyn Diagnostic</code> stuff unnecessary since it could just be one struct with code, location, description and fix</p>



<a name="239883698"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239883698" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239883698">(May 22 2021 at 16:19)</a>:</h4>
<p>there's still the problem of needing to duplicate all these <code>hir_*</code>-level error enums for the <code>hir</code> facade though</p>



<a name="239883828"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239883828" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239883828">(May 22 2021 at 16:21)</a>:</h4>
<p>also, it does leave the whole problem of "what's full set of possible diagnostics, and which queries do we need to run for it" to the IDE crate, but maybe that's not actually a problem, since we need to implement the code to describe the error and possibly provide a quickfix there anyway</p>



<a name="239884149"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239884149" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239884149">(May 22 2021 at 16:27)</a>:</h4>
<p>with <a href="https://github.com/rust-analyzer/rust-analyzer/issues/8713">rust-analyzer/rust-analyzer#8713</a>, maybe the interface for diagnostics in the IDE crate could just be basically a function taking some kind of HIR node, and then the driver could even automatically handle doing the tree walk, deciding for which files to calculate diagnostics, and <code>#[allow]</code> etc.</p>



<a name="239891836"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239891836" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239891836">(May 22 2021 at 18:41)</a>:</h4>
<p>For production of diagnostics, I think there are clearly two very dissimilar paths. </p>
<p>Some diagnostics are emitted during analysis. For example, you are inferring types, and you fail to resolve a method call, so you should emit a diagnostic here.</p>
<p>Some diagnostics exist completely orthogonal to the standard code analysis. For example , doing unsafe op outside of unsafe block has no bearing on the actual analysis. This diagnostics should be computed by a separate walk over the code, after the analysis is done.</p>



<a name="239891944"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239891944" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239891944">(May 22 2021 at 18:43)</a>:</h4>
<blockquote>
<p>maybe the answer is that we shouldn't / don't need to have a unified concept of diagnostics in the HIR crates,</p>
</blockquote>
<p>Yeah, the <code>dyn Diagnostic</code> is a wholly unnecessary boondoggle, we should eliminate that. I think that maybe we should do that first, and then maybe  a better design emerges.</p>



<a name="239892670"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239892670" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239892670">(May 22 2021 at 18:55)</a>:</h4>
<blockquote>
<p>For production of diagnostics, I think there are clearly two very dissimilar paths.</p>
</blockquote>
<p>Yeah, that's what I mean -- and I think the first path doesn't necessarily need to be viewed as part of the diagnostics infrastructure, it's just some additional outputs of some queries. Then there's only the second path, which can fully live in the IDE crate.</p>



<a name="239939405"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239939405" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239939405">(May 23 2021 at 10:00)</a>:</h4>
<p>or to be a bit more concrete, do you think that whatever hir_ty produces should already have diagnostic codes or even a 1:1 relationship to the diagnostics shown to the user in the end?</p>



<a name="239939441"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239939441" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239939441">(May 23 2021 at 10:01)</a>:</h4>
<p>No, I think ty should just emit enough data to reconstruct the diags</p>



<a name="239939518"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239939518" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239939518">(May 23 2021 at 10:02)</a>:</h4>
<p>IIRC, we kinda already emit such data, we just then convert it to the <code>dyn Diagnostic</code>. If we remove this conversion, and just expose the data as is, the architecture becomes less messy</p>



<a name="239939652"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239939652" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239939652">(May 23 2021 at 10:04)</a>:</h4>
<blockquote>
<p>Then there's only the second path, which can fully live in the IDE crate.</p>
</blockquote>
<p>I am not sure about this though. Feels like the second path is still subdivided in two. </p>
<p>From the implementation point of view, "don't call unsafe fn outside of unsafe block" and "don't call filter_map().next()" are exactly equivalent. But they are different in semantics. The first should be a compilation error, the second is a lint</p>



<a name="239939846"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239939846" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239939846">(May 23 2021 at 10:08)</a>:</h4>
<p>so you'd expect the first one to still happen in some <code>hir_*</code> crate? I guess if we were implementing a full compiler, it would need to, so that it knows to not generate code, but that seems like the only meaningful difference?</p>



<a name="239940240"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239940240" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239940240">(May 23 2021 at 10:15)</a>:</h4>
<p>I don't know. I guess, I'd expect it to happen in the <code>hir</code> crate, without the suffux (or in a special <code>hir_diagnostics</code> crate). </p>
<p>Argh, this is reeealy hard. One side of me thinks "let's move this to <code>ide</code> and just implement that on top of hir". But then another part thinks that the most natural way to express this diagnostics is for our desugared expressions.</p>



<a name="239940352"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239940352" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239940352">(May 23 2021 at 10:17)</a>:</h4>
<p>Hm, I guess this is a real design question here: </p>
<ul>
<li>we have an idea that the IDE sees only the nice, close-to-source HIR view of the code</li>
<li>at the same time, inside the compiler, we have a number of IRs, which are more convenient to work with</li>
</ul>
<p>Some IDE features could be implemented on top of such IRs more conveniently then on top of HIR. What to do?</p>



<a name="239942553"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239942553" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239942553">(May 23 2021 at 10:56)</a>:</h4>
<p>Hm, mulling over this some more, it seems this is exactly the layering trade off we  want to make. </p>
<ul>
<li>inside the complier, we want to use fine-grained API and many specific IRs</li>
<li>outside of the compiler, we want to present a unified and simple API</li>
</ul>
<p>The simple API make easy things simple, but it might make complex things impossible or overly awkward. Down the line, I expect us to find at least some situations where, when writing an assist, we wish we had a direct access to the database. But I am not a fan of exposing this -- it's useful that things like assits don't know that we are using chalk inside. </p>
<p>I wonder, how roslyn exposes thinkgs like control flow graph?</p>



<a name="239942888"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239942888" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239942888">(May 23 2021 at 11:02)</a>:</h4>
<p><a href="https://docs.microsoft.com/en-us/dotnet/api/microsoft.codeanalysis.semanticmodel.getoperation?view=roslyn-dotnet-3.9.0#Microsoft_CodeAnalysis_SemanticModel_GetOperation_Microsoft_CodeAnalysis_SyntaxNode_System_Threading_CancellationToken_">https://docs.microsoft.com/en-us/dotnet/api/microsoft.codeanalysis.semanticmodel.getoperation?view=roslyn-dotnet-3.9.0#Microsoft_CodeAnalysis_SemanticModel_GetOperation_Microsoft_CodeAnalysis_SyntaxNode_System_Threading_CancellationToken_</a></p>



<a name="239942955"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239942955" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239942955">(May 23 2021 at 11:03)</a>:</h4>
<p><a href="https://docs.microsoft.com/en-us/dotnet/api/microsoft.codeanalysis.flowanalysis.basicblock?view=roslyn-dotnet-3.9.0">https://docs.microsoft.com/en-us/dotnet/api/microsoft.codeanalysis.flowanalysis.basicblock?view=roslyn-dotnet-3.9.0</a></p>



<a name="239943005"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239943005" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239943005">(May 23 2021 at 11:04)</a>:</h4>
<p>so roslyn does expose some additional IR besides syntax nodes.</p>



<a name="239943246"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239943246" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239943246">(May 23 2021 at 11:08)</a>:</h4>
<p>yeah, I would expect us to expose some more information through HIR when we need it and can figure out a nice API for it. And if the <code>unsafe</code> diagnostic needs such detailed information that it's nicer to implement inside HIR, I would expect that we implement some query in there that does the hard analysis part and then just use that for the final diagnostic living in <code>ide</code>. That's kind of orthogonal to the question of "should there be a concept of errors in the HIR crates" though, or "should the unsafety diagnostic live in HIR because it would be a compiler error"</p>



<a name="239943596"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239943596" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239943596">(May 23 2021 at 11:15)</a>:</h4>
<p>Yeah, I don't think hir crates need to know about diagnostics, they need to emit facts, and its up to the higher layers to translate some of the facts into errror</p>



<a name="239961135"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239961135" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239961135">(May 23 2021 at 16:10)</a>:</h4>
<p>Let me try to look into what it takes to remove dyn diagnostics (unless someone is already looking into this...)</p>



<a name="239978494"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/239978494" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#239978494">(May 23 2021 at 21:12)</a>:</h4>
<p>Predictably, I ended up polishing the generate getter assist</p>



<a name="240059133"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/240059133" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#240059133">(May 24 2021 at 14:31)</a>:</h4>
<p>Question: how we should test diagnostics in <code>hir_xxx</code> crates? At the moment, we rely on the Diagnostic crate to render messages an ranges. </p>
<p>I am tempted to just write some glue code for "rendering for testing"</p>



<a name="240078550"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/240078550" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#240078550">(May 24 2021 at 16:52)</a>:</h4>
<p>Here's how far I got: <a href="https://github.com/rust-analyzer/rust-analyzer/pull/8973">https://github.com/rust-analyzer/rust-analyzer/pull/8973</a></p>



<a name="240078705"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/240078705" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#240078705">(May 24 2021 at 16:54)</a>:</h4>
<p>I am not trying to remove dyn right of the bat, and just want to move it further up the stack. Modulo test, it successfully jumped from hir_expand to hir_ty</p>



<a name="240104070"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/240104070" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#240104070">(May 24 2021 at 20:02)</a>:</h4>
<p>Hm, I am somewhat unsatisfied with our testing story here.... </p>
<p>I think we don't want low-level code to be concerned with figuring out the specific range to be highlighted. That means we won't be able to use precise ranges in our low-level tests.</p>
<p>But we do want to have tests for ranges somewhere, so we'll have to duplicate tests somewhat for hight-level diagnostics...</p>



<a name="240200991"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/240200991" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#240200991">(May 25 2021 at 15:02)</a>:</h4>
<p>Finished first part of this: <a href="https://github.com/rust-analyzer/rust-analyzer/pull/8973">https://github.com/rust-analyzer/rust-analyzer/pull/8973</a></p>



<a name="242452725"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/242452725" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#242452725">(Jun 12 2021 at 14:13)</a>:</h4>
<p>Thinking more about this, I think it would be fine to only test diagnostic in the IDE layer. This is similar to various other auxilary data we have in InferenceResults. We don't have dedicated tests for method resolution tables and such, and that seems fine. </p>
<p>So, we'll probably just completely remove manual test traversals to collect diagnostics, and instead will have a giant hight-level "UI" test suite</p>



<a name="242506443"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/242506443" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#242506443">(Jun 13 2021 at 11:57)</a>:</h4>
<p><a href="https://github.com/rust-analyzer/rust-analyzer/pull/9245">https://github.com/rust-analyzer/rust-analyzer/pull/9245</a> finally got to the "end game" here, now need to only refactor the other diagnostics</p>



<a name="242509580"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/242509580" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#242509580">(Jun 13 2021 at 13:08)</a>:</h4>
<p>Next question is, what should diagnostic store? At the moment, <code>hir</code> structs store AstPtr's, and that's stupid. </p>
<p>A diagnostic emerges from the guts of the compiler with something like <code>ExprId</code>. The <code>hir</code> crate then converts that to a ptr, often going via a syntax node. Finally, an IDE converts the ptr back to syntax node for rendering purposes. That's clearly suboptimal :D</p>



<a name="242509809"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/242509809" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#242509809">(Jun 13 2021 at 13:14)</a>:</h4>
<p>imo we should have a HIR wrapper for <code>ExprId</code> (or the full tree-based HIR) and provide that, and then IDE can use that to map to the AST node</p>



<a name="242509819"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/242509819" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#242509819">(Jun 13 2021 at 13:14)</a>:</h4>
<p>can we just add a simple <code>hir::Expr</code> for now?</p>



<a name="242510087"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/242510087" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#242510087">(Jun 13 2021 at 13:19)</a>:</h4>
<p>Yeah, that's reasonable, although I am not sure about "just simple" part <span aria-label="rofl" class="emoji emoji-1f923" role="img" title="rofl">:rofl:</span> </p>
<p><code>hir::Expr { id: ExprId, parent: DefWithBodyId }</code> probably won't cut it</p>



<a name="242510101"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/242510101" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#242510101">(Jun 13 2021 at 13:19)</a>:</h4>
<p><code>ExprId</code> are desugared, but I am pretty sure that <code>hir::Expr</code> wants to be surface-level expr</p>



<a name="242512046"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/242512046" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#242512046">(Jun 13 2021 at 14:00)</a>:</h4>
<p>hm. do we do anything other than <code>source_map.expr_syntax</code> to get the AST pointer right now though?</p>



<a name="242512103"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/242512103" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#242512103">(Jun 13 2021 at 14:01)</a>:</h4>
<p>ok the one for record fields is a bit more complicated</p>



<a name="242525699"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/242525699" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#242525699">(Jun 13 2021 at 19:06)</a>:</h4>
<p>Diagnostic sink is gone: <a href="https://github.com/rust-analyzer/rust-analyzer/pull/9256">https://github.com/rust-analyzer/rust-analyzer/pull/9256</a></p>



<a name="242739637"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics%20working%20group%3F/near/242739637" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/Diagnostics.20working.20group.3F.html#242739637">(Jun 15 2021 at 14:20)</a>:</h4>
<p>I've moved diagnostics to a separate crate, I think these all "long overdue" changes I want to make in this area</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>